|
|
|
|
|
|
|
relational database tables. Because the words customer and account are so pivotal in your domain, the architects, analysts, and lead designers agree that these should be nominal domain classes. Let's keep them. |
|
|
|
|
|
|
|
|
The noun customer is another representation of customer information. You already decided to incorporate a nominal class named customer, so this is a repetition. You can discard it. |
|
|
|
|
|
|
|
|
The noun system is a more generic reference to your application name, which is Samsona Bank Teller System. If you want the analysis-view use case to remain generic enough to be reused across your enterprise, it's probably best to leave it as system. However, if you decide that the actual application name is more meaningful, by all means use the full system name. Because you have already identified the system as the Samsona Bank Teller System, let's use the full name. Thus, you just replace the word system with Samsona Bank Teller System. |
|
|
|
|
|
|
|
|
The noun checking history is an interesting one. For simplicity's sake, you have omitted the fact that there is more than one kind of account in banking systems. Furthermore, in your domain (or context), the domain experts and users did not mention any particular type of account. After a quick meeting with these stakeholders, you agree that for this release of the system, you will not consider the various kinds of accounts. Therefore, checking history becomes a nominal class, but not a specialization of the Account class you already identified in your earlier analysis. This is a very, very important point that many OO novices miss entirely. Do not create classes and actors simply because it seems logical. Stick to the project plan. Such deviations, although thoughtful, usually slow down the object-oriented process, which prompts many to exaggerate the length of time OO projects typically take. However, with practice or a good mentor, the project will soon fall into a rhythm, and slowness will give way to deliveries of the system in increments and iterations. |
|
|
|
|
|
|
|
|
The noun Telecheck is, in English grammar, an indirect object; it's on the receiving end of the action initiated by the teller. However, you don't know exactly what Telecheck means, so you ask the experts. They tell you that it's a vendor who provides research services to the bank. The teller views the information supplied by Telecheck to determine whether the customer can establish an account. On further investigation, you discover that there is an electronic interface between the bank teller's machine and the vendor. Through this interface, the teller sends customer information to Telecheck for verification and research. The research results are returned directly to the terminal screen in the current system. Based on this behavior, you conclude that Telecheck is an actor you can stereotype as an external system. Therefore, you promote it from noun to distinct actor. You'll have to update your use-case model with your new actor. Figure 2.6 shows the new use-case model, including the Telecheck external system actor. |
|
|
|
|
|